Automated testing for applying migrations in a named schema #146
Conversation
|
Code changes to the Dockerfile look good and makes sense to me. I ran the test and the docker built just fine and the tests performed as described. I also applied the migrations and that worked as well. One question though I'm getting this message when I fire up the Docker image: Do you know the cause of that? Whatever is causing that doesn't seem to interfere with the migration but it may create confusion when folks see it. |
|
I'm approving as it works as expected. My question above is just a question. |
|
An update. @laceysanderson and I spoke by Slack and she reminded me that the warning about the 37 SQL migrations that don't follow the migration naming scheme are left over from when we migrated Chado to use Flyway. This can probably be fixed if we dig into it. This warning has been present for quite a while and not related to this PR. |
|
Great, thanks @spficklin! Are you ok with me merging this one as well @scottcain? It simply extends the last one to allow Chado to be installed into a separate schema in the docker and creates a workflow that tests this with schema installed in a schema named |
Issue #145
This PR builds on and is dependant on PR #143. It alters the dockerfile to allow you to name the schema you want chado installed in and creates some automated workflows that do this. This way we can confirm that there is nothing in the migration that is specific to the public schema!
Testing
This really just needs a code review and to confirm the automated testing passes. If you want to be extra thorough or are curious, then you can build the image with a set schema name as follows:
This will install chado into a schema named
teacup. You can usepsql -U postgres -h localhost -d chadowith the passwordchadotestto look at the schema. Specifically,\dt public.*should only have a flyway table and\dt teacup.*should list out the whole chado schema + a flyway migrations table.